1. Field of Technology and Background
With very few exceptions, most of camera-phones manufactured today have used a serial data bus for transferring the image information from the camera to the phone engine containing memory and processors for storing, showing, processing and/or sending the images further. A block called compact camera port (CCP) is the block on the phone engine side that connects the phone engine to the aforementioned serial bus (sometimes called CCP bus), wherein said serial bus typically consists of differential clock lines (clock+ and clock−) and differential data lines (data+, data−) only.
Cameras in camera-phones in many respects behave like video cameras and output images continuously. In order to provide synchronization of these image frames, e.g., to know where one single image starts and where it ends, synchronization codes are used. The synchronization codes are typically 32-bit patterns which need to be univocal. Each synchronization code must be different from others, and the synchronization codes must not appear within the image data itself (otherwise the image data would be treated as a synchronization code and not as an image data). The CCP block is a hardware block that compares incoming data in a bit-by-bit manner to detect the synchronization codes. The CCP block has a serial first in-first out (FIFO) buffer for 32 bits. The bits received from the camera go through the FIFO buffer and, when a synchronization code is detected, the bits belonging to that synchronization code are removed and the state machine in the CCP block is updated accordingly.
Currently, four synchronization codes have been defined as follows:                Frame Start Code, FF00000216, is inserted by the camera to the beginning of each image frame,        Frame End Code, FF00000316, is inserted by the camera to the end of each image frame,        Line Start Code, FF00000016, is inserted by the camera to the beginning of each line within an image, and        Line End Code, FF00000116, is inserted by the camera to the end of each line within an image.        
The data on the CCP bus is sent bytewise least significant bit (LSB) first, so for example the Frame Start Code is a binary number (1st bit) 1111 1111 0000 0000 0000 0000 0100 00002 (32nd bit).
2. Problem Formulation
The problem rises from the fact that the synchronization codes must not appear within the image data itself as stated above. Cameras are starting to support a joint photographic expert group (JPEG) output format, in other words they can compress the image into the JPEG format before sending it, thus reducing the bandwidth and storage memory requirements. However, the JPEG format has been standardized and there is no way to prevent the occurrence of the synchronization codes inside JPEG data. Therefore it is unavoidable that the synchronization code mistakenly appears bitwise within the video data signal. For example if data F8070000F816 is sent, (each byte is sent LSB first), it appears on the CCP bus as 0001 1111 1110 0000 0000 0000 0000 0000 0001 11112 with the underlined part corresponding to the bit pattern of the Line Start Code. In this situation the CCP block will mistakenly find and remove a look-alike Line Start Code in the video data signal.
Therefore, in order to successfully transfer, for example, JPEG data over the CCP block in the phone engines, channel coding known as a false sync code protection (FSP) must be used to change the JPEG data before it is sent. And similarly, the data should be properly decoded once it is received. The method for FSP encoding which is currently used or to be used in cameras in the visible is summarized below as follows.
The camera monitors the JPEG data it is producing. Whenever one of the bit patterns shown in Table 1 appears, the camera adds the padding byte, the number A516 (or 1010 01012), in its output after a zero byte n, thus breaking a bit pattern that can generate a synchronization code.
TABLE 1Bit patterns (“?” means that it can be “1” or “0”).byte n − 2byte n − 1byte n???? ????21111 111120000 000021??? ????20111 111120000 0000211?? ????20011 111120000 00002111? ????20001 111120000 000021111 ????20000 111120000 000021111 1???20000 011120000 000021111 11??20000 001120000 000021111 111?20000 000120000 00002
Once the data is received in the phone engine, the extra A516 padding bytes need to be removed and FSP decoding must be performed. Note that not all A516 bytes of the received data must be removed, because A516 bytes will appear in the original JPEG data as well and those bytes must be left intact while decoding.
Currently, there is no hardware to remove the inserted A516 padding bytes on the phone engine side, so the decoding of the JPEG data has to be done by software (for example within the camera driver).
3. Prior Art Solutions
In Nokia phone 3650 the problem was circumvented by adding 2 padding bytes for each 2 bytes of the JPEG data. Therefore the decoding process was very simple, but at the expense of bandwidth and memory requirements (e.g., for 30 kilobytes of the JPEG data, 60 kilobytes need to be sent over the CCP block).
A simple solution to the problem outlined above can be comparing the received FSP encoded data byte-by-byte to the eight patterns given in Table 1. However, this is a slow solution, even if it is optimized so that initially only zero bytes are being looked for, and once found, the two previous bytes are taken into closer inspection. This is because JPEG data contains a considerable amount of zero bytes, and all the eight comparisons would require that the unessential bits are first masked out before comparison can be made (each of the patterns requiring different bits to be masked out). Using this byte-by-byte comparison approach it was estimated that the comparison would take 141 instructions for comparing the input data against all eight patterns.